Eligibility gate — Discord membership and minimum account age before a key is issued (lore 0189) - #230

… key is issued

The issue path moves behind a fresh OAuth round-trip (action=issue in the
signed state): the callback checks Stellar Discord membership
(GET /users/@me/guilds/{guild}/member with the just-exchanged user token)
and the snowflake-derived account age against two operator-seeded SSM
parameters, and only then runs 0187's reconciler. Three outcomes, not two:
only Discord's own 10007/10004 on a 404 is 'not a member'; 401/403/429/5xx,
unrecognised shapes and an absent pending field refuse without accusation.
The /key route goes fully read-only — a session cookie alone can cause zero
control-plane writes — and answers no_key when there is nothing to reveal.
Scope becomes exactly 'identify guilds.members.read', compared as a set.

'Get my API key' becomes a top-level link into the issue round-trip; the
key section fetches the (now read-only) reveal on mount and renders the
five ?issue= landing states in the wording this task decides: not-a-member
names the server and links discord.gg/stellardev, too-young renders the
backend's wait_secs as a wait rather than a rejection, and could-not-verify
is explicitly not an accusation. Landing params are one-shot — read once,
stripped from the URL — which also closes 0186's O10 stale-banner item.
The landing page states both prerequisites before the visitor authenticates.

…docs

compute-stack passes PORTAL_GUILD_ID_PARAM and PORTAL_MIN_ACCOUNT_AGE_PARAM
(names only, unconditional) and states the read grant explicitly beside the
plan-id one. verify-openapi-routes gains check 7: the handler carries both
names exactly, and no synthesized template may CREATE either parameter — a
CDK-owned parameter would be restored by the next deploy, un-flipping
production back to the test guild after 0179. The runbook gains §2a (the
put-parameter seeding, the ownership split, the no-redeploy property) and
its scope step is rewritten to the two-scope done state; the README gains
the local procedure for the gate and its refusal states.

…asurements

Step 0's tables stay empty with a dated deferral — the archived 0180 notes
were found unmeasured and the prerequisites are operator-owned; the code is
written to the documented safe rules with each unmeasured behaviour behind
one reversible arm. Ticks the code-side acceptance criteria and names the
two operator steps that remain.

All seven were verified against the code before acting; none was a
false positive.

The reconcile deadline is now derived from what is left of the
invocation rather than reused from 0187, where the reconciliation was
the whole request. With four network calls in front of it the worst
case reached ~29s against a 15s Lambda, which answers an API Gateway
502 instead of ?issue=failed and can leave a key created but never
attached.

The authorize URL sends prompt=none. Three comments asserted that
Discord does not re-prompt for consent on repeat authorisation and the
parameter that makes that true was never sent, so every issue, every
retry after a refusal and every future rework was a full consent
screen — the cost the per-action model's own justification denied.

?issue=cancelled and ?issue=denied give the issue flow the pre-check
pair sign-in has had since 0186. Without them a cancelled press landed
on ?signin=cancelled, whose banner renders only in the signed-out
branch an issue round-trip has by definition left: the visitor came
back to an unchanged dashboard with nothing said.

guild_id() and member_url now share one is_snowflake. Only the consumer
checked the shape, so a guild name passed the cold-start probe and then
refused every visitor as unknown, indefinitely. The task's parameter
table named such a value, and is corrected with it.

The key fetch runs once per load again — load() depended on an inline
callback prop, so reporting the key re-fired the mount effect — and
?issue=ok no longer renders beside "you have no API key yet", a window
that offered a second key to somebody who had just been given a first.

Left alone deliberately: the wildcard apigateway:DELETE on /apikeys/*,
which 0194's checklist already names verbatim, mitigation included.

Corrects two claims the round made stale — the redirect count and the
test totals — and adds decisions 18 to 22 plus the two entries under
Issues Encountered.

The entry worth keeping is why a comment can be load-bearing and still
describe code that was never written: three places asserted that
Discord does not re-prompt for consent, and nothing sent prompt=none.

Neither was a criterion this slice's code could meet: both are manual
prerequisites owned by the operator, and both remain recorded in Step
0's status note, in Future Work, and in the two runbooks they name.

What is left is eleven criteria, all met, all asserted by tests.

PR #230's five findings and two risks, the five problems the pass over the
whole diff turned up, and decisions 23 to 26 for the choices taken without
asking: the `prompt=none` narrowing, the redirect-only issue path, the
re-worded `?issue=failed`, and `?issue=ok` reporting the key's existence
by itself.

Records one finding as raised-not-taken (the same `502` dead end on the
sign-in arm, which is 0186's code and 0186's documented decision), and the
rebase onto 0188's tip as the remaining pre-merge step.

rustc 1.98.0, released 2026-08-18, began passing
`-Wl,--fix-cortex-a53-843419` on aarch64-unknown-linux-gnu. Zig's linker
rejects the argument outright, so every aarch64 link fails and the
`Build Lambda bootstraps` step dies on the first crate that links —
`crc-fast`, pulled in by aws-smithy-checksums.

Nothing in this repo caused it: PR #227 passed on 1.97.1 and PR #230
failed on 1.98.0 with an identical Cargo.lock and the same
cargo-lambda 1.9.1 / zig 0.16.0 pair. `develop` did not show it because
its rust job has not run since 22 July.

cargo-zigbuild filters the argument since v0.23.0 (rust-cross/
cargo-zigbuild #451, fixed by #452), but cargo-lambda 1.9.1 still
vendors 0.20.1 — so upgrading cargo-lambda cannot reach the fix today.
Both pins come off together once a cargo-lambda release carries
zigbuild >= 0.23.

cargo-lambda is pinned as well because `pip3 install cargo-lambda`
resolves at run time, which is how the vendored zigbuild version — the
half that actually carries the fix — could change under a green build
without a commit.

Considered and rejected: `cargo lambda build --compiler cargo` on the
native ARM runner. ubuntu-24.04 ships glibc 2.39 against
provided.al2023's 2.34, so the failure would move from CI to the
deployed function.